The Third Generation Partnership Project (3GPP) is a collaboration between groups of telecommunications associations to make a globally applicable third generation (3G) wireless communications system.
The UMTS network architecture includes a Core Network (CN), a UMTS Terrestrial Radio Access Network (UTRAN), and at least one user equipment (UE). The CN is interconnected with the UTRAN via an Iu interface.
The UTRAN is configured to provide wireless telecommunication services to UEs, referred to as wireless transmit/receive units (WTRUs) in this application, via a Uu radio interface. A commonly employed air interface defined in the UMTS standard is wideband code division multiple access (W-CDMA). The UTRAN comprises one or more radio network controllers (RNCs) and base stations, referred to as Node Bs by 3GPP, which collectively provide for the geographic coverage for wireless communications with the at least one UE. One or more Node Bs is connected to each RNC via an Iub interface. The RNCs within the UTRAN communicate via an Iur interface.
FIG. 1 is an exemplary block diagram of the UE 200. The UE 200 may include a radio resource control (RRC) entity 205, a radio link control (RLC) entity 210, a medium access control (MAC) entity 215 and a physical (PHY) layer 1 (L1) entity 220. The RLC entity 210 includes a transmitting side subassembly 225 and a receiving side subassembly 230. The transmitting side subassembly 225 includes a transmission buffer 235.
FIG. 2 is an exemplary block diagram of the UTRAN 300. The UTRAN 300 may include an RRC entity 305, an RLC entity 310, a MAC entity 315 and PHY L1 entity 320. The RLC entity 310 includes a transmitting side subassembly 325 and a receiving side subassembly 330. The transmitting side subassembly 325 includes a transmission buffer 335.
The 3GPP Release 6, introduced high-speed uplink packet access (HSUPA) to provide higher data rates for uplink transmissions. As part of HSUPA, a new transport channel, the enhanced dedicated channel (E-DCH), was introduced to carry uplink (UL) data at higher rates.
The MAC sublayer is configured to determine the number of bits to be transmitted in a transmission time interval (TTI) for the E-DCH transport channel. The MAC sublayer may be configured to perform an E-DCH transport format combination (E-TFC) selection process. The relative grant and absolute grants received on the E-RGCH and E-AGCH adjust the maximum allowable E-DPDCH to DPCCH power ration at which a WTRU may transmit.
FIG. 3 shows an overview of the RLC sub-layers. The RLC sub-layer consists of RLC entities, of which there are three types: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM) RLC entities. An UM and a TM RLC entity may be configured to be a transmitting RLC entity or a receiving RLC entity. The transmitting RLC entity transmits RLC PDUs and the receiving RLC entity receives RLC PDUs. An AM RLC entity consists of a transmitting side for transmitting RLC PDUs and a receiving side for receiving RLC PDUs.
Each RLC entity is defined as a sender or as a receiver depending on elementary procedures. In UM and TM, the transmitting RLC entity is a sender and a peer RLC entity is a receiver. An AM RLC entity may be either a sender or a receiver depending on the elementary procedure. The sender is the transmitter of acknowledged mode data (AMD) PDUs and the receiver is the receiver of AMD PDUs. A sender or receiver may be at either the UE or the UTRAN.
There is one transmitting RLC entity and one receiving RLC entity for each TM and UM service. However, there is one combined transmitting and receiving RLC entity for the AM service.
Both an UM RLC entity and a TM RLC entity use one logical channel to send or receive data PDUs. An AM RLC entity may be configured to use one or two logical channels to send or receive both data PDUs and control PDUs. If only one logical channel is configured, then the transmitting AM RLC entity transmits both data PDUs and control PDUs on the same logical channel.
The AM RLC entity may be configured to create PDUs, wherein, the RLC PDU size is the same for both data PDUs and control PDUs.
Currently, an RLC entity is “radio unaware” or not aware of current radio conditions. However, in the UL direction, an RLC entity may be “radio aware” or aware of current radio conditions, because both RLC and MAC protocols are located in the same node. As a result, an RLC PDU size may be determined based on an instantaneous available data rate.
However, when the RLC entity is designed to be “radio unaware,” the RLC entity generates RLC PDUs of a maximum size. Depending on current radio conditions and a given grant, this may result in the generation of more than one PDU per TTI. Unfortunately, if the generated RLC PDU is larger than a selected E-DCH transport format combination (E-TFC) size, then the generated RLC PDU may be segmented.
Both “radio aware” and “radio unaware” RLCs have advantages and disadvantages. The main disadvantages of radio unaware” are (a) large overhead in case a small fixed RLC PDU size is used and (b) large error rates due to residual hybrid automatic repeat request (HARQ) errors in case MAC segmentation is used with a large fixed RLC PDU size. (Note: residual HARQ error=the transmission of the improved MAC (MAC-i/is) PDU has failed. If there is a large number of segments, the chance that any of the MAC-i/is PDUs carrying a segment fails is larger, thus the RLC PDU error rate increases.)
As stated above, a “radio aware” RLC entity generates RLC PDUs as a function of the E-TFC size of a MAC PDU (transport block size). As a result, there is minimal overhead and low RLC PDU error rate due to residual HARQ errors since the RLC PDUs do not need to be segmented at the MAC. However, a “radio aware” RLC entity may not be able to generate an RLC PDU at a given TTI because the generation of the RLC PDU within a short amount of time may require too much processing power.
A “Radio aware” RLC entity, will generate RLC PDUs that match the transport block size which is optimal for minimizing the RLC PDU error rate due to residual HARQ errors, however the “radio aware” RLC entity will have a much higher overhead for very small E-TFC sizes and a lower overhead for large transport block sizes. Because a “radio aware” RLC generates a large RLC PDU when there is a large E-TFC selection, there are problems when the large RLC PDU needs to be retransmitted and the E-TFC selection decreases in size. Further, the retransmission of the large RLC PDU requires the generation of a large number of MAC segments. As a result, there may be an increase of RLC PDU error rate due to HARQ residual errors.
Accordingly, there exists a need for a method for use in an RLC entity that generates RLC PDUs such that RLC overhead and RLC PDU error rates due to HARQ residual errors are both reduced.
Therefore, methods of selecting the proper RLC PDU size within the specified bounds would be desirable. More specifically, methods to determine when the RLC PDU size should be calculated and which value the RLC PDU size should be set to would be desirable.